Le présent document recense les anomalies et problèmes sur les
données à plat du PROPAGE contenues dans le fichier
all_data_propage20240201.xlsx. Il propose aussi des
solutions de curation.
Il existera a priori un travail de normalisation dû au changement du questionnaire (ajout de la fiche gestion) et de la saisie des données qui s’est effectuée entre vers 2019/2020 quand exactement?. Quelles données ont été conservées/perdues lors du changement?
path <- "../all_data_propage20240201.xlsx"
data <- read_excel(path)
J’ai eu des problèmes dans la suite pour travailler sur les id à cause de l’apparition d’un espace insécable (peut être format à préciser lors de l’extraction?). Je reformate les id à problème
data$id_releve <- gsub(intToUtf8(8239),"", data$id_releve)
data$site_id <- gsub(intToUtf8(8239),"", data$site_id)
id_releveCette variable correspond en fait à la session d’observation. Pas de
NAs.
Dans les nouvelles saisies, un id_releve apparaît 39
fois (une ligne par taxon observé ou non).
Avant changement, un id_releve = 1 observation
effective d’un taxon.
On va identifier les sessions qui ne répondent pas à cette nouvelle norme. On s’intéresse également à la date de la session pour repérer à quel moment s’est effectué le changement.
Ci-dessous le code pour récupérer les id des anciens relevés
data_releves <- data |>
select(id_releve, releve_date)
data_releves_count <- data_releves |>
count(id_releve)
data_releves <- data_releves_count |>
left_join(data_releves, by = "id_releve") |>
arrange(desc(releve_date))
#Table des anciens relevés (ainsi que des relevés dont la `date` est `NA`)
data_anciens_releves <- filter(data_releves, n!=39) |>
unique()
#Table des nouveaux relevés respectant la norme, une ligne = un taxon observé OU non
data_nouveaux_releves <- filter(data_releves, n==39) |>
arrange(releve_date) |>
unique()
#Id des anciens relevés
id_anciens_releves <- data_anciens_releves$id_releve
Commentaires:
Apparition des nouveaux relevés en 2019 (12 sessions)
Disparition totale des anciens relevés à partir de 2021. Sauf la
session id_releve= 12690 en 2022
(pourquoi?)
En 2019 et 2020, chevauchement des 2 types de relevés
Apparition d’un nouveau problème : 23 sessions dont la date n’est par renseignée! (comment corriger?, y a t il une variable qui permette de déduire une chronologie )?
id_structure et
structure_nom124 structures distinctes + les NAs.
Les dernières valeurs manquantes sur les structures apparaissent en 2020 (car champ devenu obligatoire dans le nouveau protocole de saisie).
Comment remplacer les NA?
Faire le lien avec d’autres sites “sur le même territoire” sur les autres années pour pouvoir compléter? Pas forcément pertinent car des sites très proches (voire un même espace) peuvent avoir plusieurs gestionnaires…
Faire le lien avec l’utilisateur? Il existe des utilisateurs qui dépendent de plusieurs structures. Pourquoi? Peut-être pas d’incohérence : un même observateur pour plusieurs structures est tout à fait possible. Cependant certains utilisateurs ont parfois renseigné leur structure, parfois non. A voir géographiquement si les sites concernés sont proches. Il n’y en a pas beaucoup quand même.
# Liste des utilisateurs qui ont parfois renseigné la structure, parfois non
user_na <- data |>
select(user_id, structure_id) |>
filter(is.na(structure_id)) |>
unique()
user_non_na <- data |>
select(user_id, structure_id) |>
filter(!is.na(structure_id)) |>
unique()
intersect(user_na$user_id, user_non_na$user_id)
## [1] "582" "158" "278" "93" "70" "77" "88"
Je ne pousse pas plus loin l’étude des valeurs manquantes dans les structures pour l’instant, il faudrait que je regarde plus largement le lien avec les autres variables (de fait, le renseignement du nom de la structure ne me paraît par primordial pour faire les analyses … )
site ,
site_id, site_coordonnees,
site_departement, site_code_postal,
transect_nomet transect_coordonneesLe code ainsi que mes essais et pérégrinations pour cette partie sont
dans le fichier Curation_geo_Progage.Rmd.
Tous les transects sont localisés, mais les sites sur lesquels ils sont situés ne sont pas tous définis.
2 sites sans aucune référence géographique (ni coordonnées, ni code
postal) : site_id= 729 et site_id= 939.
A. Site 729
Je suspecte fortement le site_id= 427 d’être le même que
le site_id= 729.
même nom site : “Parc Marcel Cachin -
Saint-Denis”
même user_id: 116
le nom de structure diffère mais quasi le même
Plaine commune - Grand Paris devenu
PT Plaine Commune, d’ailleurs suite au changement du mode
de saisie
le transect du Site 729 se situe exactement dans le polygone défini pour le site 429
Solution: On peut remplacer les coordonnées
NA du site_id= 729 par celles du
site_id= 429.
B. Site 939
Le site_id= 939 correspond certainement au
site_id= 5. Il y a même quasi-correspondance de transect
(voir transect 3 du site 5) *(Peut-on considérer que c’est le
même?)**
Remarques:
En cherchant des sites pouvant matcher, le site_id=
1484 est aussi apparu!
Pour ces trois sites site_id= 5, 939, 1024 il y a
quand même beaucoup de similitudes (même user_id=116 par
exemple, encore lui): faut-il fusionner ou pas pertinent? Il y a même
plusieurs transects similaires (voir cartes)… Se pose le problème du
suivi du transect dans le temps…
En passant, penser à résoudre le problème du format des id lors de l’extraction - car besoin de reformater dans la table à plat
On créée une table de correspondance nommée data_sites
dans laquelle on remplace les valeurs manquantes.
# Création de la table
data_sites <- data |>
select(site_id, site, site_coordonnees, site_departement, site_code_postal) |>
unique()
# Code de remplacement dans la table data_sites (uniquement)
data_sites[data_sites$site_id=="939", 3:5] <- data_sites[data_sites$site_id=="5", 3:5]
data_sites[data_sites$site_id=="729", 3:5] <- data_sites[data_sites$site_id=="427", 3:5]
Commentaire : Ok a priori ça fonctionne comme ça!
Après avoir remplacé les valeurs NA des deux sites
précédents, il ne reste que 6 sites sans code postal. On le fait donc à
la main : grâce à une petite recherche Google ainsi qu’une vérification
de la localisation.
# Liste des sites sans code postal
site_ss_ref <- c(20,128,271,417,1305,1306)
# codes postaux correspondants
codes_postaux <- c(35131, 59800, 22260,49300,69730, 69730 )
data_sites <- data_sites |>
mutate(site_code_postal = case_when(
site_id == 20 ~ 35131,
site_id == 128 ~ 59800,
site_id == 271 ~ 35131,
site_id == 417 ~ 49300,
site_id == 1305 ~ 69730,
site_id == 1306 ~ 69730,
TRUE ~ site_code_postal
))
Finalement il n’en reste plus que 2: site_id= 597 et
site_id= 1382.
A. Site 597
Ce site_id= 597 a pour nom bois de vincennes. Le
transect correspondant est effectivement situé au coeur du bois, mais
dans une entité qui semble indépendante (la Ferme de Paris, gestionnaire
= Mairie de Paris).
Le site_id= 34 correspond egalement au bois de vincennes
(mais géré par la DEVE/SAB/DBV).
QUID de la correction : Définir le polygone autour de la ferme de Paris à l’intérieur du bois? ou bien garder tout le bois?
B. Site 1382
Impossible de trouver dans la table une correspondance avec le Jardin d’agronomie tropicale (ni par nom, ni par département).
Cependant, Le Jardin est une entité du Bois de Vincennes, située à son extremité orientale (94 130, mais limitrophe 70012). Coordonnées (48.839839266697716, 2.46666394884083)!
Structure gestionnaire, idem que le site_id=34, c’est le
DEVE/SAB/DBV.
En fait le transect du site_id=1382 d’autres transects
du site_id= 34, donc on peut conclure que c’est le même
site.
Correction: On remplace le NA par les
coordonnées du site_id= 34. Et pour ne pas avoir de trou,
on va finalement faire la même chose pour le site précédent.
D’où la petite mise à jour de la table data_sites
# code pour veut remplacer des coordonnées manquantes
data_sites[data_sites$site_id=="597", 3] <- data_sites[data_sites$site_id=="34", 3]
data_sites[data_sites$site_id=="1382", 3] <- data_sites[data_sites$site_id=="34", 3]